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(54) Method and system for effecting migration of application among heterogeneous device 



(57) The present invention provides a method and 
system for implementing migration of an application 
among heterogeneous devices. An application consists 
of sets of one or more component. The application run- 
ning on a source device and the hardware configuration 
of the target device are examined to port the application 



to the target device by selecting at least one component 
from each set that fits to run on the target device. The 
running state of the application that exits on the source 
device is captured and sent to the target device. The 
target device loads the ported application and instanti- 
ates it, using the captured running state of the applica- 
tion. 
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Description 

BACKGROUND OF THE INVENTION 

5 [0001] This application relates to a method and system for effecting migration of an application among heterogeneous 
devices or devices with different hardware configurations. 

[0002) Migration is a process in which an application running on one device stops Its task and moves to another 
device where it resumes the task exactly from the point where it terminated the task on the first device. In this regard, 
migration differs from remote execution, which is a process in which an application moves from one device to another 

10 device where it makes a fresh start irrespective of the state of the application that existed on the first device. 

[0003] The need for mobility may be the main driving force of evolution of computing devices. The desktop computer 
has transformed itself into the notebook computer. The PDA and the intelligent pager are new species that recently 
joined the evolutional tree. Even the cellular phone has recently evolved into having computing capability. Now, these 
computing devices begin speaking with each other in the form of data communication through various communication 

is networks, such as a wired or wireless LAN, cellular network Bluetooth, and PAN (Personal Area Network). 

[0004] The evolution of the computing devices has significant impact upon our life and is changing our business and 
work environments. Traditionally, since a PC was fixed on a desk and not movable, it was possible to work or process 
data only the places where a PC with equivalent software was found. Nowadays, however, mobile computing devices, 
such as a notebook computer, PDA and cellular phone, with sufficient computing capability are readily available to us. 

20 The users of these mobile devices may desire to capitalize the mobility of the devices to the full extent. Imagine how 
efficient and productive the uses can become if they can continue doing their work with a mobile computer at remote 
places or even while they are traveling. Suppose, for instance, that a mobile phone or PDA user is working on planning 
a business tip on line with a desktop computer in the office but interrupted by a call for a meeting at a remote place. 
In such a scenario, the user may desire to continue working on the business trip planning with the mobile phone or 

25 PDA on a train or bus on the way to the meeting place or during brakes of the meeting. 

[0005] To respond to this need, the concept of migration of an application has developed, i.e., the concept that an 
application moves from one computing device (source device) to another computing device (target device), along with 
the state of the application. Migration addresses two technical issues: (1 ) uniformity of an application; and-(2) continuity 
of the execution of an application. 

30 [0006] The first issue comes from the differences in hardware configuration of computing devices. They are Indeed 
different in almost every way - computation power, memory size, screen size, means for inputting data, etc. Because 
of these differences, the computing devices are usually loaded with different applications peculiar to their hardware 
configurations, yet performing the same job. For instance, we have "Microsoft Outlook" for desktop PCs, "Mail" for 
Palm PDAs and "PCS Mail" for SPRINT PCS Cell Phones. All of them are different applications but perform the same 

35 e-mail function. Users may wonder if they really have to learn how to use all of these different applications to just send 
and receive e-mails. Under the concept of migration, the same application runs on both source and target devices. 
Thus, migration serves to eliminate users' time for learning different applications, as well as software developers' time 
for developing different applications. 

[0007] The second issue may probably be more challenging. The application restored on the target device is simply 
40 not ready to resume the task until it reestablishes the state of the application that existed on the source device. The 
state of the application includes the execution state and the data state. You could manually reconstruct the state of 
the application on the target device through troublesome operations, such as saving the application state before the 
application moves from the source device and reestablishing it after the application is restored on the target device. 
In a migration process, however, the application moves from the source device, along with the application state, and 
45 restart itself on the target device with the application state. Therefore, the application is ready to resume the task upon 
arrival on the target device. 

[0008] A number of studies have been reported on various attempts to implement migration of an application. Sig- 
nificantly, most of these studies were conducted, using Java based software architectures. Java is a programming 
language and not dependent on the hardware configuration of a device on which it runs. More specifically, Java pro- 
so grams are complied into bytecodes, which are high-level, machine-independent codes, and then interpreted to run by 
a hypothetical interpreter, called a Java virtual machine (JVM). Since Java programs are machine independent, they 
run on different hardware platforms without the need to perform any special porting work for the programs. Because 
of this property, Java is often characterized as 'Write Once, Run Anywhere. 9 

[0009] Because of its machine-independent property, Java is certainly useful and advantageous for implementing 
55 migration of an application among heterogeneous devices, i.e., devices with different hardware configurations. In fact, 
the past studies show that migration of an application under Java-based software architecture was successful at least 
in limited circumstances. But the problem of these prior studies is that migration of an application was conducted 
between selected source and target devices that were comparable and sufficiently resourceful for implementing mi- 
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gration of an application. In other words, migration of an application implemented in the prior studies was not actually 
achieved in really heterogeneous environments. 

[0010] Obviously, the difficulty arises when an application is migrating from a resourceful device, such as a desktop 
PC, to a less resourceful device, such as a PDA. Compared to the desktop PC, the PDA is limited in its hardware 
5 resources, such as processing speed, memory size, availability of a permanent storage, and reliability of network 
connectivity. The question is whether migration of an application is nonetheless possible from a desktop PC to a PDA 
even when the application requires PC-level resources for its running and does not simply fit on the PDA. None of the 
past studies addresses this question. 

10 BRIEF SUMMARY OF THE INVENTION 

[0011] It is therefore the objective the present invention to provide a method and system for achieving migration of 
an application among truly heterogeneous computing devices. To this end, in accordance with the present invention, 
an application that is migrating adaptively reconfigures itself during the migration process to fit on a target computing 

is device, or ports itself to the target device. 

[0012] The porting process according to the present invention is 'unique. In the present invention, an application 
consists of a plurality of standalone software components. Components are colored into a device independent ("DP) 
group and a device dependent ("DD") group. Dl components can run on different hardware platforms. But DD compo- 
nents require specific hardware configurations for their execution. So the DD group is formed with sets of alternative 

20 components designed to run on different hardware platforms. Thus, in addition to Dl components, an application in- 
cludes DD components selected from the sets that fit to run on the device on which the application is running. 
[0013] The migration process according to the present invention begins with examining an application running on a 
source device that is about to migrate. The application is examined to determine DD components of the application 
presently running and availability of their alternative DD components. The hardware configuration of the target device 

25 is also examined to pose the application to a target device by selecting DD components that will fit on the target device. 
The selected DD components, as well as the Dl components, are then loaded on the target device. At the same time, 
the running state of the application that exists on the source device is captured and transferred to the target device. 
The migration process completes by instantiating the application on the target device, using the captured running state 
of the application. 

30 [0014] In the migration operation according to the present invention, the functions of an application may be appor- 
tioned among more than one target devices. Dl components are functional components and can run on different plat- 
forms. But there may be a case in which a D1 component in an application about to migrate performs a task that 
requires computation capability beyond the capability of the target device. In the present invention, such a task is 
allotted to a third device with sufficient computation capability. Thus, the Dl component migrates to the third device 

35 while the other components of the applications migrate to the target device. Thereafter, the target device and the third 
device, communicating with each other, work together to execute the application. . 

[0015] Thus, according to the present invention, the application running on the source device and hardware config- 
uration of the target device are examined to port the application to the target device. Then, the ported application is 
loaded on the target device. At the same time, the running state of the application that exists on the source device Is 
40 captured and transferred to the target device. The target device instantiates the application on it, using the captured 
running state ofthe application. An application consists of sets of one or more components, and the application is ported 
to the target device by selecting from each set at least one component that best fits on the target device. 
[001 6] The application is loaded on the target device from one or more third devices which may include the source 
device. 

<5 [0017] There may be more than one target device, and the application is loaded dividedly on the more than one target. 
BRIEF DESCRIPTION OF SEVERAL VIEWS OFTHE DRAWINGS 

[0018] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate 
50 embodiments ofthe invention and, together with the description, serve to explain the advantages and principles of the 
invention. In the drawings, 

Fig. 1 is a block diagram showing the system architecture of a Roam system according to the present invention; 
Fig. 2 is a block diagram showing a basic migration operation according to the present invention; 
55 Fig. 3 is a block diagram showing a migration operation according to a first embodiment of the present invention; 

Fig. 4 is a flowchart showing details of the migration operation shown In Fig. 3; 

Fig. 5 is a block diagram showing a migration operation according to a second embodiment of the present invention; 
Fig.6 is a flowchart showing details ofthe migration operation shown in Fig. 5; 
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Fig. 7 is a block diagram showing a computer network used in examples implementing the present invention. 
Fig. 8 is a block diagram showing a migration operation conducted in a first example. 
Figs. 9(a), (b) and (c) are displays on notebook, PDA and PC used in the first example. 
Fig. 10 is a block diagram showing a migration operation conducted in a second example; 
5 Figs. 11(a) and (b) are displays on notebook and PDA used in the second example. 

DETAILED DESCRIPTION OF THE INVENTION 

[0019] Reference will now be made in detail to an implementation of the present invention as illustrated in the ac- 
10 companying drawings. The preferred embodiments of the present invention are described below, using a Java based 
software system. However, it will be readily understood that the Java based software system is not the only vehicle for 
implementing the present invention, and the present invention may be implemented under other types of software 
systems. 

15 A. Overview of Migration Operation 

[0020] Migration of an application according to the present invention is executed on a resource-aware application 
migration ("Roam") system specifically designedto implementthe present invention. Fig. 1 is a block diagram illustrating 
the architecture of the Roam system. As shown in Fig. 1 , the Roam system is built on the top of Java Virtual Machine 
20 (JVM), PersonalJava Virtual Machine (PJVM) or other types of Virtual Machine, which runs on the top of the native 
operating system of a device. VM acts like an abstract computing machine, receiving bytecodes and interpreting them 
by dynamically converting them into a form for execution by the native operating system. 

[0021 ] "Roam let" is a program interfaced directly with a user, such as a word-processing program or a mail program, 
which is written in Java and executed by JVM, PJVM or other types of VM. In the present invention, a Roamlet migrates 

25 from a source device to a target device under the control of the Roam system. The Roam system contains a Roam 
agent that provides an environment for runtime migration of a Roamlet. The Roam agent performs a critical role for 
implementation of migration and thus must reside in both source and target devices before migration takes place. 
Between the Roam system and a Roamlet, a set of Roamlet APIs (Application Program Interface) reside which receive 
instructions from the Roam agent and perform actual operations for migration of the Roamlet. 

30 [0022] Fig. 2 is a block diagram showing a basic migration operation according to the present Invention. In Fig. 2, a 
Roamlet 1 is about to migrate from a source device 2 to a target device 3. In step 1 , upon a call for migration, a Roam 
agent 4 on the source device 2 begins negotiation with a Roam agent 5 on the target device 3. The negotiation process 
will be discussed later in detail and therefore briefly summarized here. During the negotiation process, the Roam agent 
4 first obtains information from the Roamlet 1 regarding the hardware requirements necessary for the Roamlet 1 to 

35 execute. The Roam agent 4 then obtains information from the Roam agent 5 regarding the hardware configuration of 
the target device 3 in order to determine whether the Roamlet 1 can run on the target device 3. To avoid getting into 
the detail here, it is assumed that the Roamlet 1 can run on the target device 3. Lastly, the Roam agent 4 gives the 
Roam agent 5 a URL (Uniform Resource Locator) on an HTTP server 6 from which the bytecode of the Roamlet 1 is 
downloadable. 

40 [0023] In Step 2, upon reception of the URL, the Roam agent 5 accesses the HTTP server 6 and downloads the 
bytecode of the Roamlet 1 therefrom. In Step 3, the state of the Roamlet 1 is captured by Roam agent 4 and sent to 
the Roam agent 5. In Step 4, the Roam agent 5 instantiates the Roamlet 1 by reestablishing the captured state of the 
Roamlet 1 that existed on the source device 2. The migration of the Roamlet 1 ends with closing the Roamlet 1 on the 
source device 2. The Roamlet 1 is now on the target device and ready to resume the task that was halted on the source 

45 device 2. 

B. Detailed Description of Migration Operation 
1 . Device Classification 

50 

[0024] Roamlets are more or less device dependent Therefore, the Roam agent on the source device must know 
the hardware configuration of the target device before migration takes place in order to determine whether a particular 
Roamlet is executable in its entirety or in part on the target device. An advantage of using Java to construct the Roam 
system is that a Java runtime system contains information indicating the hardware configuration of the device on which 
55 it is running. Currently, there are several Java runtime systems available to provide tailored runtime environments for 
different computing devices. Table 1 shows exemplary Java runtime systems and their structures. 
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Table 1 



Profiles 


Personal 
Profile 
[2.5MB ROM 
+ IMRAM] 


RMI Profile [2.5MB ROM -h IM 
RAM] 


Foundation 
Profile [1MB 
ROM+512K 
RAM] 


PDA Profile 
[512KB] 


MID Profile 
[136KB ROM 
+ 32KB RAM] 


Configurations 


CDC (512KB ROM + 256K RAM] 


CLDC [160 KB] 


Virtual 
Machines 


PJVM 


CVM 


KVM 
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20 



25 



[0025] As shown in Table 1 , the Java runtime system consists of three layers: VM; configuration; and profile. Con- 
figuration is a Java API specification. Profile specifies extension to a configuration API. There are three types of VM 
shown in Table 1 : PJVM (Personal Java Virtual Machine); CVM (Compact Virtual Machine); and KVM (Kilo Virtual 
Machine). These VMs are designed to adapt to specific hardware configurations. For instance, the KVM is suitable for 
devices with 16/32-bit RISC/CISC microprocessors, and with as little as 160 K of total memory available. The PJVM 
is discussed in "PersonalJava™ Technology --White Paper", Sun Microsystems, August 1998, which is incorporated 
therein by reference. The CVM is discussed in M JSR #000036 J2ME™ Connected Device Configuration", Sun Mi- 
crosystems, August 2000, which is incorporated therein by reference. The KVM is discussed in "J2ME CLDC/KVM 
Palm Release: Release Notes/CLDC 1.0", Sun Microsystems, May 2000, which is incorporated therein by reference. 
[0026] Table 1 also shows two configurations: CDC (Connected Device Configuration); and CLDC (Connected Lim- 
ited Device Configuration), and five profiles: Personal Profile; RM1 Profile; Foundation Profile; PDA profile and MID 
(Mobile Information Device) profile. Each of these configurations and profiles is also designed to function effectively 
with a specific hardware platform. These configurations and profiles are discussed in detail in "Java Specification 
Requests," Java Community Press, which is, for example, available via URL http://java.sun. com/aboutJava/commu- 
nityprocess/s earch.html, and is incorporated herein by reference. 

[0027] Thus, by looking into the Java runtime system on a device and examining the types of VM, configuration and 
profile in the system, it is possible to identify the hardware configuration of the device fairly accurately. It will, however, 
be understood that the Java runtime system is not the only source for identifying the hardware configuration of a device, 
and one skilled in the art will readily appreciate that there are other sources available for the purpose. For example, 
the Roam agent can acquire detailed or precise information on the hardware configuration of a device from a special 
device capability file created on the device. The hardware information can be obtained from the device capability file 
by querying the underlying native operating system running on the device. 
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[0028] A Roamlet consists of a plurality of distributed software components. Each component contains one or more 
objects executable to perform the assigned task of the component. Components in a Roamlet are interconnected to 
one another and perform the purpose of the Roamlet in their entirety. These components are categorized into a device 
dependent ("DD") group and a device independent ("Dl") group. A DD component is a software component whose 
execution requires specific hardware configuration. In the present invention, one implementation, or one DD compo- 
nent, is provided for one type of hardware platform. An example of DD component is a GUI (Graphical User Interface) 
component, which requires a different GUI library depending on a type of input and display hardware on which it acts. 
For a Roamlet that requires inclusion of a GUI component are prepared for the Roamlet to run on different hardware 
platforms. Those GUI components include a GUI component for PCs, GUI component for PDAs, and GUI components 
for other platforms. When the Roamlet is migrating to a target device, one GUI component that is most suitable to the 
hardware configuration of the target device is selected and instantiated on the target device. 
[0029] On the other hand, a Dl component is a functional component In the present invention, one implementation, 
or one Dl component, is prepared for multiple hardware platforms. Because of its functional characteristic, the Dl 
component is expected to run on different hardware platforms. It is, however, recognized that some Dl components 
require specific hardware capabilities, such as high computation capability, if a Roamlet is migrating to a target device 
that is short of the hardware capability as required by a Dl component in the Roamlet, the Dl component will be off- 
loaded from the Roamlet and migrate to a third device, as will later be explained in detail. 

[0030] Thus, for each Roamlet, one set of Dl components is prepared, and multiple sets of DD components are 
prepared so that the Roamlet can run on different hardware platforms. Please note that although multiple sets of DD 
components are prepared for one Roamlet, in a Roamlet actually running on a device, only one set of DD components 
is instantiated on the device that best fits on the hardware configuration of the device. As will be described fully in the 
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following section, in order to select a set of DD components that best fits on a target device, the Roam agent on a 
source device examines all sets of DD components prepared for a Roamlet about to migrate and compares the hard- 
ware configuration required by each set with the hardware configuration of the target device. 
[0031] These Dl and DD components are programmed in Java and compiled into bytecode and stored on a server, 
5 such as the HTTP server 6 discussed above. These components are selectively downloaded on a target device from 
the server according to the hardware configuration of the target device. Please note, however, that if the source device 
has a sufficiently large memory, the Dl components and all sets of the DD components of a Roamlet may reside on 
the source device irrespective whether or not they are in use. 

10 3. Dynamic Instantiation 

[0032] Turning now to Fig. 3, details of the migration operation will be discussed. In Fig. 3, a source device 10 is a 
PC, and a target device 11 is a PDA. The PC 10 and the PDA 11 are connected to each other through a communication 
network 12 and identified with unique IP addresses (Internet Protocol address) on the communication network 12. A 
15 Roamlet 13 is currently running on the PC 10 and about to migrate to the PDA 11 . Upon a call for migration, a Roam 
agent 14 residing on the PC 10 begins negotiation with a Roam agent 15 residing on the PDA 11 . 
[0033] Fig. 4 is a flowchart showing the migration operations step by step. In step 10, the Roam agent 14 examines 
the Roamlet 13 and its components running on the PC 10. In examining the Roamlet 13, the Roam agent 14 identifies 
the Dl components and DD components of the Roamlet 13 currently running on the PC 1 0 and alternative DD compo- 
se nents available for execution of the Roamlet 13 on different hardware platforms. Suppose that the Roamlet 13 includes 
a GUI component 16 which runs only on PCs and that the Roam agent 14 finds that an alternative GUI component 1 7 
for PDAs is available for execution of the Roamlet 13 on PDAs. 

[0034] In Step 11 , the Roam agent 14 contacts the Roam agent 15 on the PDA 11 and requests information on the 
hardware configuration of the PDA 11 . In response to the request from the Roam agent 14, the Roam agent 15 examines 

25 the Java runtime system running on the PDA 11 (Step 12). Based on the types of the VM; configuration and profile 
contained in its own runtime system, the Roam agent 15 determines the hardware settings of the PDA 11 , such as 
computation power, screen size and memory size. The Roam agent 15 then sends information regarding the hardware 
configuration of the PDA 1 1 back to the Roam agent 1 4 (Step 1 3). Please note that if more detailed or precise information 
on the hardware configuration of the PDA 11 needs to be obtained, the Roam agent 15 may look into the devise 

30 capability file located in the underlying native operating system on the PDA 11 . 

[0035] In Step 14, the Roam agent 14 determines, based on the information from the Roam agent 15 regarding the 
hardware configuration of the PDA 11 , which components can migrate to the PDA 11 and which components cannot. 
All the Dl components of the Roamlet 1 3 are migratable regardless ofthe hardware configuration of the PDA 1 1 . Some 
of the DD components ofthe Roamlet 13 may also be migratable to the PDA 11 . For DD components that are not 

35 migratable because of the hardware differences between the PC 10 and the PDA 11 , the Roam agent 14 searches for 
alternative components executable on the PDA 11 . 

[0036] in Step 15 : the Roam agent 14 sends the Roam agent 15 URLs of the migratable Dl and DD components 
and the alternative DD components stored on the HTTP server 6. In the example illustrated in Fig. 3, the PC GUI 
component 16 currently running on the PC 10 is not migratable to the PDA 11. The Roam agent 14 thus sends the 

40 Roam agent 15 a URL of the PDA GUI component 17 stored on the HTTP server 6. 

[0037] In Step 16, the Roam agent 15 accesses the server 6 with the URLs sent from the Roam agent 14 and begins 
downloading the components stored in the form of bytecodes in the server 6. At the same time, in Step 1 7, the Roam 
agent 14 captures the running state of the Roamlet 13 on the PC 10 and sends the captured state to the Roam agent 
15. In Step 18, the Roam agent 15 deploys the Roamlet 13' on the PDA 11 and reestablishes the captured state in the 

45 deployed Roamlet 13'. The Roamlet 13' is now ready to resume the task on the PDA 11. The Roam agent 15 advises 
the Roam agent 14 in Step 19 that the Roamlet 13' has been successfully replicated on the PDA 11. In response, the 
Roam agent 14 removes the Roamlet 13 from the PC 10 (Step 20). 

[0038] in the present invention, capturing and reestablishing ofthe running state ofthe Roamlet 13 are implemented, 
using Java object serialization. Java object serialization offers a convenient way to capture and reestablish the running 

50 state of a Java program. In the embodiment shown in Fig. 3, the Roam agent 14 invokes Java object serialization on 
the PC 1 0 to serialize the running state of all Java objects that exist in the Roamlet 1 3. The Roam agent 1 5 also invokes 
Java serialization on the PDA 11 to deserialize the serialized running state into the Roamlet 13' on the PDA 11. The 
state serializable by Java object serialization includes the values of all variables of each obiect existing in the Roamlet 
13. By using the Java object serialization, most of the running state of the Roamlet 13 can be captured on the PC 10 

55 and reestablished on the PDA 11 . 

[0039] However, two types of running state elude Java object serialization. One type of running state is peculiar to 
the Roam system. That is, the running state of a DD component to be replaced with an alternative DD component 
cannot be reestablished in the alternative DD component. A DD component and its alternative component often com- 
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10 



prise different objects, and the running state of a DD component is meaningless to its alternative component. Accord- 
ingly, a conversion process is necessary to preserve the running state between a DD component and its alternative 
component. For instance, returning to Fig. 3, suppose that the PC GUI component 16 implements user interface with 
check buttons, whereas the PDA GUI component 1 7 implements user interface with choice buttons. In order to transfer . 
the running state of the PC GUI component 16 into the PDA GUI component 17, the Roam agent 14 maps the values 
of the check buttons to the choice buttons and converts the values into those of the choice buttons. 
[0040] The second type of running state elusive to Java object serialization is the execution state of VM interpreting 
the Roamlet 13. Java object serialization cannot access inside VM. Therefore, the execution state of VM, such as the 
call stack, is not serializable. To cope with this, the Roam agent 14 may allow migration to take place only at specific 
points where the call stack is minimal in order to minimize an amount of the execution state lost. 
[0041] The following is an exemplary Roamlet API for implementing the basic migration process under the Roam 
system: 
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public abstract class Roamlet Implements Serializable { 
public Roamlct(Object0 args); 
public synchronized final void irograte(Stniig hostname); 
public synchronized "boolean onlnitializationO; 
public synchronized boolean onRemovalO', 
public synchronized boolean onArrivalQ; 
pubHc synchronized boolean extt(); 

static final void instantiflte(Stnng className, ObjectO initArgS, String codebase); 

i _ — : — — ^— 
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[0042] All Roamlets must extend the class Roamlet. The method "migrateO" is to dispatch a Roam let to the target 
device indicated by "hostname." The method M onlnitialization()" is called when the Roamlet is instantiated for the first 
time on the target device. The method M onRemoval()" is called before the Roamlet is removed from the source device 
after it is successfully migrated to the target device. The method "onArrival() B is called when the Roamlet arrives at the 
target device. The method "exitO" is to remove the Roamlet from the source device. The method "instantiationQ" is to 
instantiate the Roamlet on the target device. After the Roamlet is instantiated on the target device, a separate thread 
is created on the target device to run it This eliminates the overhead of creating and running multiple virtual machines 
on the target device. 

[0043] The following is an exemp lary Roamlet API for maintaining a group of alternative DD components that performs 
the same function: 



40 



Public abstract class Roamlet implements Serxolizable { 

public synchronized boolean addDDC£npoiUBlDcSCUst(RDamC^ 
desoListQ); 

Li — 
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[0044] The method "addDDComponentDescList() H is to add a descriptor list, i.e., RoamComponentDescQ. This de- 
scriptor list lists alternative DD components in relation to hardware settings. For example, the descriptor list includes 
all of the alternative GUI components, such as a PC GUI component, a PDA GUI component, and a cell phone GUI 
component When migration takes place, one component is selected from the descriptor list that is best suited to the 
target device. 

4. Apportion of Functions Among Devices 

[0045] There may be cases in which some Dl components indispensable for execution of a Roamlet are not execut- 
able on the target device due to insufficiency of the hardware resource of the target device. In such cases, the Roam 
system apportions the functions of the Roamlet among devices, I.e., the Roam system allows-the components-to mi- 
grate to different target devices. Figs. 5 and 6 are a block diagram showing such an apportioning operation and a 
flowchart detailing the operation. In Fig. 5, the same reference numbers as used in Fig. 3 are assigned corresponding 
devices and software components. 

[0046] In Fig. 5, as in Fig. 3, the Roamlet 13 is about to migrate from the source device 10, a PC, to the target device 
11, a PDA. In step 30, the Roam agent 14 examines the Roamlet 13 and identifies the Dl components and DD com- 
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ponents of the Roamlet 13 currently running on the PC 10. Suppose that the Roamlet 13 includes a Dl component 18 
that performs a heavy, memory consuming computation task the execution of which requires computation capability 
beyond that of the PDA 11 , and thus" although being a Dl component, the component 18 cannot run on the PDA 11 . 
Suppose further that the Dl component 1 8 is indispensable for the execution of the Roamlet 1 3, but there is no alter- 

5 native component available for PDAs. ' 

[0047] in Step 31 , the Roam agent 14 contacts the Roam agent 15 on the PDA 11 and requests information on the 
hardware configuration of the PDA 11 . In response to the request from the Roam agent 14, the Roam agent 15 examines 
the Java runtime system running on the PDA 1 1 and determines the hardware configuration of the PDA 11 (Step 32). 
The Roam agent i 5 then sends in Step 33 information regarding the hardware configuration of the PDA 1 1 back to the 

10 Roam agent 14. 

[0048] in Step 34, the Roam agent 14 then determines, based on the hardware information from the Roam agent 
15. which components of the Roamlet 13 can migrate to the PDA 11 and which components cannot Because of the 
limited computation capability of the PDA 11, the Roam agent 14 determines that the component 18 cannot migrate 
to the PDA 1 1 . The Roam agent 1 4 has already determined in Step 30 that there is no alternative component available 
is to the PDA 11. 

[0049] In Step 35, the Roam agent 14 first determines whether or not the computation component 18 Is off-loadable 
from the Roamlet 1 3. If it is determined-that the component 1 8 is off-loadable, the Roam agent 1 4 moves on to continue 
the migration operation. If the component 18 is not off-loadable from the Roamlet 13, migration simply fails, and the 
Roam agent 15 aborts the migration operation. If the component 18 is off-loadable, the Roam agent 15 then begins a 

20 search for a third device capable of executing the component 18. The user may participate in this device searching 
and appoint a particular device to which the user wants the component 1 8 to migrate. Suppose that the Roam agent 
1 4 successfully finds a server 1 9 that has sufficient computation power to run the component 1 8 on it 
[0050] In Step 36, the Roam agent 1 4 sends the Roam agent 1 5 URLs of the components of the Roamlet 1 3 stored 
on the server 6 that are migratable to the PDA 11 . In addition, the Roam agent 14 sends a Roam agent 20 on the 

25 server 19 a URL of the component 18 stored on the server 6. The Roam agent 15 downloads, using the specified 
URLs, the bytecodes of the components from the server 6 (Step 37). Likewise, the Roam agent 20 downloads the 
bytecode of the component 1 8 from the server 6 (Step 38). At the same time, in Step 39, the Roam agent 1 4 captures 
the running state of the Roamlet 13 and sends the captured state to the Roam agent 15 and the captured state of the 
component 18 to the Roam agent 20. The Roam agent 15 instantiates the Roamlet 13 M on the PDA 11 (Step 40), using 

30 the captured state from the Roam agent 14. Similarly, the Roam agent 20 instantiates the component 1 8 on the server 
1 9 (Step 41 ). The Roam agents 1 5 and 20 advise the Roam agent 1 4 that the Roamlet 1 3" and the component 1 8 are 
replicated respectively on the PDA 11 and the server 19 (Steps 42 and 43). The Roam agent 14 then removes the 
Roamlet 13 from the PC 10 (Step 44). The Roamlet 13" is ready to resume the task on the PDA 11 . 
[0051] Under the Roam system, it is possible for the Roamlet 13" to migrate back to the PC 10 from the PDA 11 . In 

35 such a reverse apportioning operation, the Roam agent 15 on the PDA 11 , which is now the source device, executes 
the procedures as shown in Fig. 4 to transfer the Roamlet 13" back to the PC 10, which Is now the target device. 
Likewise, the Roam agent 20 transfers the component 1 8 back to the PC 1 0. Please note that some of the components 
running on the PDA 11 may have become unmigratable back to the PC 10. If such components exist, the components 
will stay on the PDA 11. 

40 [0052] The following is an exemplary Roamlet API for performing apportion of functions: 



public abstract class Roamlet implements Serializablc { 

public synchronized boolean addDICoinponeo tDesc(RoanCotnponcntDesc desc); 
public synchronized RoanConpanent getConcpoiimt(String id); 
public synchronized boolean registers erverDevice(Strbg hostname); 
public synchronized boolean rcglstcrServerDeviccs(Slring hostnamesQ); 

public class RoamComponcntDesc { 

public RoamCornp oncntDesc(Stxing id, String elas sname, String 
TcqDeviceCapability, boolean ofiloadable, boolean xeverseAppoitioii, ObjectQ 
initAig8>, 

>; 

public class RoamComponcnt; „ I 

55 

[0053] Each Roamlet component extends the class RoamComponent. The method "addDIComponentDescO" is 
called to add a descriptor, RoamComponentDesc, for each of its DD components. The descriptor contains information 
on how to instantiate each of the DD components, i.e., for each of the DD components, it contains information regarding 
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its unique identifier (id), the name of class to be instantiated (classname), the required device capability to run the 
component (reqDeviceCapability), whether the component is off-loadable (offloadable), whether the component is re- 
verse-apportion -able (reverse Apportion), and parameters for the constructor (initArgs). The method "getComponent 
(id)" is called to retrieve the references to the components (using id) after they are instantiated on the target device. 
5 The method M registerServerDevice() M is called to register all devices to which the components are off-loadable.. 

C. Examples 

[0054] Experiments were conducted to implement the present invention, using the computer network shown in Fig. 

10 7. The network comprises a notebook 30, a PDA 31 , Casio E-125, and a PC 32. Windows 2000 OS and Standard VM 
(JVM) run on the notebook 30 and the PC 32. Windows CE OS and PersonalJava VM (PJVM) run on the PDA 31 . The 
notebook 30 is connected to the network through a wireless LAN 33. The PDA 31 and the PC 32 are connected to the 
network through a wired LAN 34. In the network, the notebook 30 is assigned an IP address of 172.21 .96.17. The PDA 
31 is assigned an IP address of 172.21.96.152. The PC 32 is assigned an IP address of 172.21.96.19. Each of the 

is notebook 30, the PDA 31 and the PC 32 is loaded with a Roamlet agent, whose code size is approximately 24 Kbytes, 
small enough to run on most devices with a Java-based software architecture. 

1. Example 1 (Hello World) 

20 [0055] As shown in Fig. 8, the notebook 30 runs a Roamlet 35, called "HelloWorid," which is about to migrate to the 
PDA 31 . The HelloWorid Roamlet 35 consists of two component: a Click component 36; and a Swing GUI component 
37. The Click component 36 counts the number of mouse clicks made by a user. The Swing GUI component 37 displays 
the count of the mouse clicks on the notebook 30. Before the migration of the Roamlet 35 from the notebook 30 to the 
PDA 31 , a couple of rules are laid down to demonstrate the functions of the Roam system. First, the Click component 

25 36 requires more hardware capability than the PDA 31 has. Second, the Swing GUI component 37 requires a Java 
Swing library for its execution. The Java Swing library is supported by Standard Java but not supported by Personal- 
Java. Thus, the Swing GUI component 37 can run on the notebook 30 and the PC 32 but cannot run on the PDA 31 . 
Alternative to the Swing GUI component 37, an AWT (Abstract Window Toolkit) GUI component 38 is made available 
for execution of the Roamlet 35. The AWT GUI component 38 requires a Java AWT library for its execution, which is 

30 supported by the PersonalJava. 

[0056] The migration of the Roamlet 35 is performed according to the rules. Thus, the Click component 36 migrates 
not to the PDA 31 but to the PC 32. The Swing GUI component 37 is discarded. Instead, the AWT GUI component 38 
is instantiated on the PDA 31 . Figs. 9 (a), (b) and (c) show the screens of the notebook 30, the PDA 31 and the PC 
32 ; respectively. Before the migration, the HelloWorid Roamlet 35 is running on the notebook 30. The click count 

35 displayed on the screen of the notebook 30 is initially zero. Each time the "Swing Click" button on the screen is clicked, 
the Click component 36 increments the count of the clicks, and the Swing GUI component 37 displays the count on 
the screen. In Fig. 9(a), the count is "3 A migration then takes place. The AWT GUI component 38 is instantiated on 
the PDA 31 , in place of the Swing GUI component 37. As shown in Fig. (b), the AWT GUI component 38 displays count 
"3" on the screen of the PDA 31 . The Click component 36 is instantiated on the PC 32 (Fig. 9(c)). In this example, the 

40 migration took less than 5 seconds. It was also observed that each time the "AWT Click" button on the PDA screen 
was clicked, the click was counted by the Click component 36 on the PC 32, and the click count displayed on the PDA 
screen was incremented. 

2. Example 2 (Connect4) 

45 

[0057] Example 2 used a game program called ,, Connect4." As shown in Fig. 1 0, the notebook 30 runs a Roamlet 
40, called "Connect4, M which is about to migrate to the PDA 31 . The Connect4 Roamlet 40 consists of two component 
a GUI component 41 ; and an Al (artificial intelligence) component 42. The Al component 42 performs the computation 
work, such as searching trees, for playing the game, and the GUI component 41 displays progresses of the game on 
so the notebook screen. Again, a couple of rules are laid down before the migration. First, the Al component 42 requires 
more hardware capability than the PDA 31 has. Second, the GUI component 41 can run on both the notebook 30 and 
the PDA 32. 

[0056] The migration of the Roamlet 40 is performed according to the rules. Thus, the GUI component 41 migrates 
to the PDA 31, but the Al component 42 migrates to the PC 32. Figs. 11 (a) and (b) show the screens of the notebook 
55 30 and the PDA 31, respectively. Before the migration, the Connect4 Roamlet 40 is running on the notebook 30 as 
shown in Fig. 11 (a). Then, a migration takes place. The GUI component 41 is instantiated on the PDA 31 , and the Al 
component 42 is instantiated on the PC 32. As shown in Fig. (b), the same display appears on the PDA 31. In this 
example, the migration took less than 5 seconds. It was also observed that the game was playable on the PDA 31 with 
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the Al component 42 instantiated on tfie PC 32. 

[0059] It will be appreciated by those skilled in this art that various modifications and variations can be made to the 
above-embodiments without departing from the spirit and scope of the invention. Other embodiments of the invention 
will be apparent to those skilled in this art from consideration of the specification and practice of the invention disclosed 
5 therein. It is intended that the specification and examples be considered exemplary only, with a true scope and spirit 
of the invention being indicated by the following claims. 



Claims 

10 

1. A method for effecting migration of an application running on a source device to a target device, comprising the 
steps of: 

(a) examining the application running on the source device and hardware configuration of the target device to 
15 port the application to the target device; 

(b) loading the ported application on the target device; 

(c) transferring to the target device a running state of the application that exists on the source device; and 

(d) Instantiating the ported application on the target device, using the running state transferred from the source 
device. 

20 

2. A method according to claim 1 , wherein the step (c) precedes the step (b). 

3. A method according to claim 1 , wherein an application consists of sets of one or more components : and the ap- 
plication is ported to the target device by selecting from each set at least one component that best fits on the target 

25 device. 

4. A method according to claim 3, wherein some of the sets each include one device-independent component, where- 
as the other sets each include a plurality of alternative device-dependent components. 

30 5. A method acco rding to claim 1 , wherein the application is loaded on the target device from one or more third devices. 

6. A method according to claim 5, wherein one or more third devices include the source device. 

7. A method according to claim 1 , wherein there is more than one target device, and the application is loaded dividedty 
35 on the more than one target device. 

8. A system for effecting migration of an application running on a source device to a target device, comprising: 

(a) a first agent that examines, in reference to hardware configuration of the target device, the application 
40 running on the source device in order to port the application to the target device and captures a running state 

of the application on the source device; and ' 

(b) a second agent that loads the ported application and instantiates it thereon, using the captured running 
state of the application. 

45 9. A system according to claim 8, wherein an application consists of sets of one or more components, and the appli- 
cation is ported to the target device by selecting from each set at least one component that best fits on the target 
device. 

10. A system according to claim 9, wherein some of the sets each include one device-independent component where- 
50 as the other sets each include a plurality of alternative device-dependent components. 

11. A system according to claim 8, wherein the second agent loads the application on the target device from one or 
more third devices. 

55 12. A system according to claim 11 , wherein one or more third devices include the source device. 

13. A system according to claim 8, wherein there is more than one target device, and the second agent loads the 
application dividedly on the more than one target device. 
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14. A computer network comprised of heterogeneous devices among which migration of an application is effected, 
comprising: 

(a) a source device on which an application to migrate runs; and 
5 (b) a target device to which the application migrates, wherein 

said source device examines the application in reference to hardware configuration of the target device in 
order to port the application to the target device and captures a running state of the application on the source 
device, and 

10 the target device loads the ported application and instantiates it thereon, using the captured running state 

of the application. 

15. A computer network according to claim 14, wherein an application consists of .sets of one or more components, 
and the application is ported to the target device by selecting from each set at least one component that best fits 

15 on the target device. 

16. A computer network according to claim 15, wherein some of the sets each include one device-independent com- 
ponent, whereas the other sets each include a plurality of alternative device-dependent components. 

20 17. A computer network according to claim 14, wherein the target device loads the application on it from one or more 
third devices. 

18. A computer network according to claim 17, wherein one or more third devices include the source device. 

25 19. A computer network according to claim 14, wherein there is more than one target device, and the application is 
loaded dividedly on the more than one target device. 



30 



35 



40 



45 



50 



55 



11 



EP 1 215 575 A2 



Roamld 



Roamlel APIs 



Roam System 



JVM/PJVM/CVM, 



Fig. 1 



Source Device 



c 



Roamlei 



c 



Roam Agent 



4 




HTTP Server 



C Roamlet Bytecodes ^ 



Step 1 



Step 2 



Fig. 2 



12 



EP 1 215 575 A2 




r i6 

17 



Fig. 3 



13 



EP 1 215 575 A2 



PC 



^ START J 



EXAMINE ROAMLET 13 



S10 



Sll 



REQUEST HARDWARE 
INFORMATION . 



S14 



DETERMINE 
MIGRATABLE 
COMPONENTS 



SIS 



SEND URLs 



S17 



CAPTURE RUNNING 
STATE 



S20 



REMOVE ROAMLET 13 



I 

( END ) 



PDA 



S12 



EXAMINE HARDWARE 



SI3 



SEND BACK 
HARDWARE 
INFORMATION 



S16 



DOWNLOAD 
COMPONENTS 



S18 



INSTANTIATE 
ROAMLET 13' 



S19 



REPORT 
INSTANTIATION OF 
ROAMLET 13' 



Fig. 4 



14 



EP 1 215 575 A2 




15 



EP 1 215 575 A2 



PDA 



S32 



EXAMINE 
HARDWARE 



S33 



SEND BACK 
HARDWARE 
INFORMATION 



S37 



DOWNLOAD 
COMPONENTS 



S40 



INSTANTIATE 
ROAMLET 13" 



S42 



REPORT 
INSTANTIATION 
OF ROAMLET 13* 



Fig.6 



PC 



( START ) S30 



EXAMINE 
ROAMLET 13 



S31 



REQUEST 
HARDWARE 
INFORMATION 



S34 



DETERMINE 
MIGRATABLE 
COMPONENTS 



S35 



SEARCH FOR 
CAPABLE DEVICE 



S36 



SEND URLs 



S39 



CAPTURE 
RUNNING STATE 



S44 



REMOVE 
ROAMLET 13 



c ?» ) 



Server 



S38 



DOWNLOAD 
COMPONENT 18 



S41 



INSTANTIATE 
COMPONENT 18 



S43 



REPORT 
INSTANTIATION 
OF COMPONENT 18 



16 



EP1 215 575 A2 



Notebook 
-Windows 2000 
-JVM 



Casio B- 125 
-Windows CE 
-PJVM 




(Wireless LAN) ' ( Wired LAN ) 

7 — ~r 



Fig. 7 



17 



EP 1215 575 A2 










mponent 




1 


<3 




§ 


M 

M 






U 










O 1 



00 




16 



EP 1 215 575 A2 




19 



EP1 215 575 A2 




EP1 215 575 A2 



QQ 
Ll_ 



Li. 




8 



>oooo 
oooooo 
oooooo 




CO 



oooooo 



oooooo 
oooooo 
oooooo 

IOOOOOO 

oooooo 



Ui 

> 
o 
s 
«r 



21 



